Request: removeLinkModuleDescriptor error when attempting to implement func

Hello,
Attached is my work in progress for restoring links to an acrhive Module, I would like to remove all linksets and LinkModuleDescriptor then recreate them base on what links are being transfered to the restore/archive module. Currently I am getting an error with the following code, any ideas?

How would you go about deleting the current linksets before transfering them to the archive module?

Thank you,
Jim

void removeLMDesc(void)
{
    Folder fol = getParentFolder (archiveModule)
        LinkModuleDescriptor linkModDesc = null
        
        for linkModDesc in fol do {
                string modSource = getSourceName(linkModDesc) 
                string modTarget = getTargetName(linkModDesc)
                if (modSource == fullName(archiveModule))
                { removeLinkModuleDescriptor(fol, modSource,modTarget) }
        }
}

DOORS: **** Translating a structured exception ****
DOORS: Version 9.3.0.0, build number 93199, built on Sep  8 2010 17:09:51.
DOORS: Whistler Workstation Service Pack 3 (Build 2600)
 
DOORS: DOORS: 32 percent of memory is in use.
DOORS: There are 1048048 total Kbytes of physical memory.
DOORS: There are 705268 free Kbytes of physical memory.
DOORS: There are 2151076 total Kbytes of paging file.
DOORS: There are 1933656 free Kbytes of paging file.
DOORS: There are 1fff80 total Kbytes of virtual memory.
DOORS: There are 1c940c free Kbytes of virtual memory.
 
DOORS: argv[0]: C:\Program Files\IBM\Rational\DOORS\9.3\bin\doors.exe
DOORS: doors.exe caused an EXCEPTION_ACCESS_VIOLATION in module <UNKNOWN> at 001B:038F52AE
DOORS: Stack trace string not available
DOORS: 001B:004EDD68 (0x00000000 0x71EF0479 0x1000E4A6 0x1000E49B) doors.exe
DOORS: 001B:0051D212 (0x0012EEF0 0x038F52B4 0x038F5298 0x71EF04AD) doors.exe
DOORS: 001B:0051D3F8 (0x0012EEF0 0x71EF0509 0x1000E4A6 0x1000E49B) doors.exe
DOORS: 001B:00F984D2 (0x71EF1A39 0x1000E4A6 0x1000E49B 0x08F9BCC8) doors.exe
DOORS: 001B:008254F3 (0x00000008 0x08F9BCC8 0x00002458 0x08F9BCC8) doors.exe
DOORS: **** end of event ****

SystemAdmin - Mon Oct 24 23:27:19 EDT 2011

Re: Request: removeLinkModuleDescriptor error when attempting to implement func
llandale - Tue Oct 25 14:43:08 EDT 2011

The Diagnostic log is useless; except by someone who is familiar with the details of the doors.exe. Its existance is interesting. Far more useful is the DXL error that would point you to the getSourceName() line of code.

OK, so I got your error, here's the problem. You are adjusting the parameters of the "for LMD in folder" loop when you delete the LMD. Once the LMD currently pointed to in the loop is deleted, DOORS gets lost when it tries to get the "next" LMD. What's the "next" number after "nothing"? Some other folks may understand the actual cause but it doesn't matter, don't do that.

Put the LMDs you want to delete into a Skip list, then after the loop delete them from the Skip

Skip skp = create()
for LMD in Folder
{  if I want to delete then put(skp, LMD, LMD)
}
for LMD in skip
{  get source and target from LMD
   removeLinkModuleDescriptor(fol, modSource,modTarget)
}
delete(skp)

That structure should be routine for all such delete things-in-a-loop.

This particular problem comes up in the "for link in obj->"*" do" loop, deleting the link. I'm suspecting that this is a problem for ALL the various "for ThisHandle in ThatHandle" loops in DXL.

Having said all that, in years past there were "assignment" and "alias" issues that prevent this sort of clever staging; resulting in a skip loop that has several ThisHandles in it, all of them the same. Don't know if that is still a problem. If it is, you can mitigate it by breaking out of the loop right after you delete an LMD, then go back into the loop looking for another one:

Done = false
while(!Done)
{  Done = true
   for LMD in fold do
   {  if I want to delete this LMD)
      {  Done = false
         delete(LMD)
         break
      }
   }
}

Louie

On a related issue, the "for ThisHandle in ThatHandle" loop also gets confused when inside the loop you put the same loop for the same handles; such as "for every out-link; find a similar out-link". Again the solution is to stage the ThisHandle in a skip list, then loop through the Skip list doing the actual work. That's important for those of us with big libraries and we don't want the main program loop to get stomped on by some library function.
The problem is similar to this situation every programmer sees in their first programming class:

for (i=0; i<10; i++)
{  for (i=0; i<100; i++)
   {}
}
Mom is right: don't mess with loop control inside the loop.

Re: Request: removeLinkModuleDescriptor error when attempting to implement func
SystemAdmin - Tue Oct 25 18:15:14 EDT 2011

Thank you for the help.

I have one additional question is how to determine an existing Linkset and delete it. I am trying to remove the linksets from an existing module and move them to the archive/restore module currently I am creating the new Linksets in the archive module but how would I go about removing the existing ones within the current module? See below code. Once again thank you.

Also I have heard that when DOORS was owned by telelogic that when you attended a DXL training, you could buy an actual DXL book does anyone know if this is still the case with IBM? I find that alot of functionality is not documented with the DXL help

Thank you,
Jim

if (!isEdit(linkSourcePath))
{ linkSourcePath = edit(fullName(source lr),false,true,true) }
Folder fol = getParentFolder (linkSourcePath)
removeLinkModuleDescriptor(fol, fullName(linkSourcePath), fullName(Source))
addLinkModuleDescriptor (fol, fullName(linkSourcePath), fullName(archiveModule), false, true, LinkModule, "")
Linkset ls = create(lm, fullName(linkSourcePath), fullName(archiveModule))

Full Function:

void InLinks(Object hObject, Object aObject)
{
 // Follow the in-links from the selected object (hObject)
  Object     hInObj          = null
  ModName_   inModRef        = null
  LinkRef    lr              = null
  Link       in_Link         = null
  Module     linkSourcePath  = null
  int        Error           = 0
  
  // find the source (other end) of the in-link
  for lr in hObject <- "*" do
  { 
    // get the full path to the link source
        // for in-links this is always in the other module
        linkSourcePath = edit(fullName(source lr),false,true,true)
        //check that the target Module still exists
        if (null linkSourcePath)  {continue}
        // check that the returned path is valid
        if (!isEdit(linkSourcePath))
        { linkSourcePath = edit(fullName(source lr),false,true,true) }
        Folder fol = getParentFolder (linkSourcePath)
        removeLinkModuleDescriptor(fol, fullName(linkSourcePath), fullName(Source))
        addLinkModuleDescriptor (fol, fullName(linkSourcePath), fullName(archiveModule), false, true, LinkModule, "")
        Linkset ls = create(lm, fullName(linkSourcePath), fullName(archiveModule))
  }
 
  // now we know for sure those modules are open, we can do the real work
  for in_Link in hObject <- "*" do
  {  
        // check the module at the other end of the link
        inModRef =  source in_Link
        if (null inModRef)        {continue}
 
        // check the object at the other end of the link
        hInObj   =  source in_Link
        if (null hInObj)          {continue}
        if (isDeleted(hInObj))    {continue} 
 
        //and finally do something useful with the source object
        Error=createLink_(hInObj,LinkModule,aObject)
        if (Error!=linkErrorNoError) { reportLinkError_(hInObj,aObject,LinkModule,"",Error) }
  }
}

Re: Request: removeLinkModuleDescriptor error when attempting to implement func
llandale - Tue Oct 25 19:01:47 EDT 2011

SystemAdmin - Tue Oct 25 18:15:14 EDT 2011

Also I have heard that when DOORS was owned by telelogic that when you attended a DXL training, you could buy an actual DXL book does anyone know if this is still the case with IBM? I find that alot of functionality is not documented with the DXL help

Thank you,
Jim

if (!isEdit(linkSourcePath))
{ linkSourcePath = edit(fullName(source lr),false,true,true) }
Folder fol = getParentFolder (linkSourcePath)
removeLinkModuleDescriptor(fol, fullName(linkSourcePath), fullName(Source))
addLinkModuleDescriptor (fol, fullName(linkSourcePath), fullName(archiveModule), false, true, LinkModule, "")
Linkset ls = create(lm, fullName(linkSourcePath), fullName(archiveModule))

Full Function:

void InLinks(Object hObject, Object aObject)
{
 // Follow the in-links from the selected object (hObject)
  Object     hInObj          = null
  ModName_   inModRef        = null
  LinkRef    lr              = null
  Link       in_Link         = null
  Module     linkSourcePath  = null
  int        Error           = 0
  
  // find the source (other end) of the in-link
  for lr in hObject <- "*" do
  { 
    // get the full path to the link source
        // for in-links this is always in the other module
        linkSourcePath = edit(fullName(source lr),false,true,true)
        //check that the target Module still exists
        if (null linkSourcePath)  {continue}
        // check that the returned path is valid
        if (!isEdit(linkSourcePath))
        { linkSourcePath = edit(fullName(source lr),false,true,true) }
        Folder fol = getParentFolder (linkSourcePath)
        removeLinkModuleDescriptor(fol, fullName(linkSourcePath), fullName(Source))
        addLinkModuleDescriptor (fol, fullName(linkSourcePath), fullName(archiveModule), false, true, LinkModule, "")
        Linkset ls = create(lm, fullName(linkSourcePath), fullName(archiveModule))
  }
 
  // now we know for sure those modules are open, we can do the real work
  for in_Link in hObject <- "*" do
  {  
        // check the module at the other end of the link
        inModRef =  source in_Link
        if (null inModRef)        {continue}
 
        // check the object at the other end of the link
        hInObj   =  source in_Link
        if (null hInObj)          {continue}
        if (isDeleted(hInObj))    {continue} 
 
        //and finally do something useful with the source object
        Error=createLink_(hInObj,LinkModule,aObject)
        if (Error!=linkErrorNoError) { reportLinkError_(hInObj,aObject,LinkModule,"",Error) }
  }
}

Although the module properties has a tab that says "Linksets" it does not manage "linksets" at all, it manages the LinkSetPairings aka LinkModuleDescriptors. So lets make sure we talk about either "linksets", those things in a linkmdoule, or LSPs or LMDs, that mapping found in module properties.

I would suppose that has you created links to your archived module you would keep track in a skip list the names of all the LinkModules you used a long the way. When done creating links you now want to remove the old linksets. Open each LinkModule edit, loop through all its "Objects", convert each objects to a "Linkset":
... Linkset ls = linkset(Object ls)
Then use the various LinkSet commands to see if this linkset involves your retired source module, and if so delete it. Then save the link module.

Louie

Seems to me you would want to query the existing LMD as to its particular properties, then apply those properties to the new LMD; specifically its Mandatory and Overrideable flags.

I guess its OK to keep deleting and creating things you have already deleted and created but it gives me the hee-bee-gee-bees. I would find all the Linksets in the source module, for each create the corresponding linkset for the archive module, create the corresponding LMD to the archive module. Then plow through the objects creating all the links. When done, delete the old linksets and old LMDs. This approach lets you find and trap and resolve errors before the critical part of the code (deleting links), such as when you lack W access to the link module.